733632 - Remove TLS version UI (Options > Advanced > Encryption > Protocols)

Status: RESOLVED FIXED

(Core Graveyard :: Security: UI, defect)

Description

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

tl;dr: Let's remove the "Protocols" option in Advanced encryption options dialog box.

Right now, we have two checkboxes:

  [X] Use SSL 3.0   [X] Use TLS 1.0

We are adding support for TLS 1.1. When we add this support, we could add another checkbox like this:

  [X] Use SSL 3.0   [X] Use TLS 1.0   [X] Use TLS 1.1

However, this would be confusing, because it is not possible to enable SSL 3.0 and TLS 1.1 without also enabling TLS 1.0; the range of enabled versions must be contiguous, so only the following choices would be valid:

  [X] Use SSL 3.0   [X] Use TLS 1.0   [X] Use TLS 1.1
  [X] Use SSL 3.0   [X] Use TLS 1.0   [ ] Use TLS 1.1
  [ ] Use SSL 3.0   [X] Use TLS 1.0   [X] Use TLS 1.1
  [X] Use SSL 3.0   [ ] Use TLS 1.0   [ ] Use TLS 1.1
  [ ] Use SSL 3.0   [X] Use TLS 1.0   [ ] Use TLS 1.1
  [ ] Use SSL 3.0   [ ] Use TLS 1.0   [X] Use TLS 1.1

Note also that the current UI lets us do this:

  [ ] Use SSL 3.0   [ ] Use TLS 1.0

which is nonsense, because at least one version must be enabled to do anything sensible.

We will have compatibility features implemented so that basically will really need to toggle these prefs, except experts. Therefore, I think about:config is a sufficient UI for controlling this feature.

Comment 1

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

> We will have compatibility features implemented so that
> basically will

            ^ nobody

Comment 2

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Attachment: Screenshot after/before patch

Here is a screenshot showing the UI after the change and before the change.

Comment 3

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Attachment: Remove TLS version UI

Comment 4

[Johnathan Nightingale [:johnath]]

This makes me very happy, and in some worlds I think I even have the authority to ui-r+ it, but at the risk of scope creeping: now that this tab is just a certificates sub-group, what do you think of renaming the tab itself to "certificates" and getting rid of the sub-grouping. It would actually make it easier for people to find the certificate management UI (for better or for worse, I guess!)

Comment 5

[Kai Engert (:KaiE:)]

I don't see the benefit or removing this altogether. I see benefit of enabling users to check which SSL/TLS protocol versions are enabled/disabled.

Rather than simply removing it, why not introduce a new style that makes more sense?

I could imagine a checkbox combined with a single radiobox, like this:

 [ ] disable access to sites protected with SSL/TLS 
  O use TLS 1.1 and TLS 1.0 and SSL 3.0
  O use TLS 1.1 and TLS 1.0
  O use TLS 1.1

(I propose the checkbox in case there are countrys where the use of SSL/TLS is completely forbidden. If such countries exist, we should consider to keep that checkbox.)

Comment 6

[Kai Engert (:KaiE:)]

I would like to hear either an "agree to remove" from Bob,

or a "justification why the UI proposed in comment 5 would hurt".

Comment 7

[Kai Engert (:KaiE:)]

Comment on attachment 603591 [details]
Screenshot after/before patch

Bob, do you have an opinion on the proposal to remove these user-visible checkboxes from preferences?

IMHO, instead of removing them, I would rather propose to see a radio button intdroduced (see my earlier comment in the bug), together with an explanatory sentence written immediately below the checkboxes.

When connecting to a secure site, the following protocols are allowed
O use TLS 1.1 and TLS 1.0 and SSL 3.0
O use TLS 1.1 and TLS 1.0
O use TLS 1.1

TLS 1.1 is the newest protocol. SSL 3.0 the oldest protocol. If you restrict the set of allowed protocols, you will be unable to connect to sites that only support the older protocols.

Comment 8

[Kai Engert (:KaiE:)]

Comment on attachment 603591 [details]
Screenshot after/before patch

Bob, are you aware of any countries where all use of SSL/TLS is completely forbidden?

Comment 9

[Kai Engert (:KaiE:)]

Argument for keeping the preferences and adding the text:

The following scenario might happen:

- a researcher/hacker discovers a flaw in SSL 3
- an exploit gets published
- the press communicates that SSL 3 is no longer secure

Instead of having users to fiddle with about:config,
I would rather be able to tell users "go to prefs, disable SSL 3".

Comment 10

[Kai Engert (:KaiE:)]

We had a discussion in today's NSS conference call. Given that most people think, having a SSL/TLS protocol version number is not necessary, I'm giving up my resistance.

However, this was based on the assumption that about:config will still contain preferences to control which protocol versions are enabled.

Comment 11

[Kai Engert (:KaiE:)]

Comment on attachment 603592 [details] [diff] [review]
Remove TLS version UI

r=kaie

Comment 12

[Alex Limi (:limi) — Firefox UX Team]

Comment on attachment 603591 [details]
Screenshot after/before patch

Oh yes.

Comment 13

[Alex Limi (:limi) — Firefox UX Team]

Additional follow-up: I agree with johnath's comment 4 in that the tab should be renamed Certificates and lose the fieldset/legend (or whatever those things are called in XUL). Whether that is trivial to implement or not, I'll leave up to you — definitely get this change landed first if the additional work will take more time.

Comment 14

[Kurt Roeckx]

Can someone comment on what the current status of this is?

Comment 15

[Zoltán Halassy]

Would two drop-down select boxes for minimum and maximum protocol versions confuse the user? It's in the "Advanced" tab anyway. The only constraint would be the MIN <= MAX.

Eg.

Minimum protocol version to use:
+------------+
| SSLv3   [v]|
+------------+

Maximum protocol version to use:
+------------+
| TLSv1.1 [v]|
+------------+

Comment 16

[Daniel Veditz [:dveditz]]

Even in the "Advanced user" case there's no practical benefit from adjusting these. These prefs had their origin back in the days when SSLv2 was known to be insecure and yet required by tons of sites on the web. Mozilla had to decide a balance between not breaking the web (enabling SSLv2) and keeping users safe (disabling SSLv2), a default that changed over time. It was a hard choice and reasonable for some users to make a different choice, thus the option.

SSLv2 is dead and buried. Twiddling the remaining protocols is a "beyond advanced" choice and doesn't need UI; about:config is sufficient.

Comment 17

[Zack Weinberg (:zwol)]

Nowadays, SSLv3 has enough breaks to qualify as insecure, yet I still fairly regularly trip over sites that don't work with it disabled.  It seems precisely analogous to the v2 situation back then.  And in the TLS 1.1 and 1.2 bugs we have lots of reports of buggy servers that can't handle being offered anything that *new*.

I like Zoltán's suggestion of "minimum" and "maximum" drop-downs, but we could potentially do even better:  Start with every site being offered the set of supported and still-secure versions.  If that doesn't work, auto-poke the server till we figure out what *does* work, then add that site to a special-case list, thus degrading security only for sites that are buggy.  In addition to smoothing out the user experience, this allows us to be fairly aggressive about declaring old protocol revs insecure -- for instance we could default-advertise *just* TLS 1.1 or even 1.2, and a carefully minimized list of ciphersuites, once we support that, without harming site compatibility.  We'd want to age sites off the special-case list so they don't get stuck on an old protocol rev forever if the servers get fixed.

The explicit UI then needs only two knobs: a list of special-cased sites with an option to delete (like the existing cookie manager), and an "under no circumstances use a protocol older than this" dropdown (for people who need to be extra cautious).

Comment 18

[Stefan Baebler]

(In reply to Kai Engert (:kaie) from comment #7)
> When connecting to a secure site, the following protocols are allowed
> O use TLS 1.1 and TLS 1.0 and SSL 3.0
> O use TLS 1.1 and TLS 1.0
> O use TLS 1.1
How would radios UI scale to TLS 1.2 (Bug #480514)?

Just adding them in proposed pattern would look like so:

When connecting to a secure site, the following protocols are allowed
O use TLS 1.2 and TLS 1.1 and TLS 1.0 and SSL 3.0
O use TLS 1.2 and TLS 1.1 and TLS 1.0
O use TLS 1.2 and TLS 1.1
O use TLS 1.2

It's a bit harder to read, but still manageable.
It's impossible to switch off just a certain protocol (eg TLS 1.1) after a vulnerability is found in it. The two knobs (min&max dropdown) has this problem too and would require something that Zack proposed in comment #17.

Comment 19

[Alex Xu]

Attachment: Screenshot with hypothetical menulist of permitted versions

Comment 20

[Alex Xu]

Attachment: Screenshot with radio buttons of permitted versions

Comment 21

[Alex Xu]

Derp, I a typo. Oh well.

Honestly, I don't know which one looks worse. Thinking that probably removing the UI altogether is the best move.

Against the argument of "but security", there are tons of security-increasing-but-really-advanced preferences to twiddle; just look at how many preferences Torbutton pokes.

Comment 22

[Justin Dolske [:Dolske]]

Attachment: Patch v.2

Let's not overthink this, please. Dan nailed it back in comment 16:

"Twiddling the remaining protocols is a 'beyond advanced' choice and doesn't need UI; about:config is sufficient."

If the day comes when we must change defaults with risk of site breakage, it's really not reasonable to tell users to go digging in the bowels of prefs to unbreak their browser. It's vastly more likely, IMO, that we'd implement something like a simple "This site might be broken, yo!" doorhanger, with a per-site override. But we can deal with that hypothetical UI in the future. No reason to keep this UI around, nor to block it on other work. The backend prefs exist, and if someone is really yearning for the UI it would make for a trivial add-on.

I've updated the patch to account for the in-content pref fork, as well as renaming the tab and clearing the now-superfluous groupbox per comment 4 and comment 14.

This doesn't _really_ need further review, but r?bsmith for approval to land immediately.

Comment 23

[Alex Xu]

Fine with me. I thought someone said that this UI was removed already in a previous version; I just wanted to get this thing moving again.

Comment 24

[Justin Dolske [:Dolske]]

Thanks for the reminder to get it moving. :)

Comment 25

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Justin Dolske [:Dolske] from comment #22)
> This doesn't _really_ need further review, but r?bsmith for approval to land
> immediately.

One problem is that we know that some people have disabled SSL 3.0 and/or TLS 1.0 and are causing themselves compatibility problems. That's why the status whiteboard says that this should land along with bug 733642, because the patch in bug 733642 resets everybody's preferences so that SSL 3.0 and TLS 1.0 are enabled. I think it is important to set these to sane values (both enabled) before we remove the UI; the reason we're removing the UI is to remove a footgun, but we should also help the people who've already shot themselves.

Thanks to Alex and rstrong, we now know that our complicated plan for bug 733642 isn't going to work, so IMO the only reasonable choices left are (a) reset the prefs to the defaults, or (b) let people keep their broken pref settings. Dolske, could you please comment in bug 733642 about what you think of those options?

Comment 26

[Alex Xu]

Poke poke poke.

Comment 27

[Justin Dolske [:Dolske]]

I commented in 733642 (sorry  for the delay).

I still think that whatever we do with the actual preferences under-the-hood is independent from removing this UI. We still have about:config, and for a rarely-used option that's good enough.

Comment 29

[Robert Kaiser]

From what I remember, it made sense to be able to enable/disable *older* ("unsafe") protocols, and we might get into that situation again. But I agree it's nonsense to even expose an option to disable the safest protocols we have implemented.

Comment 30

[Dave Garrett]

Suggestion: Just have a checkbox labeled exactly for the known use case and nothing else. e.g.:

[] Disable older security protocols (SSL 3.0 & TLS 1.0)

Comment 31

[Dave Garrett]

(or just SSL 3.0 for now if TLS 1.1+ isn't supported enough yet, which I guess is the case)

Comment 32

[Zack Weinberg (:zwol)]

"Disable encryption protocols with known security flaws", maybe?  With tooltip reading something like "Flawed protocols are only used to communicate with servers that don't support more secure protocols.  If you check this box, your online activity will theoretically be harder to eavesdrop upon, but some websites may break."

Comment 33

[cloos]

Do note that there are broken but important web sites which fail unless one disables tls1.2 and even 1.1 in one’s browser.  

Turning off versions will remain important forthe foreseable future.

That said, about:confg is a perfectly resonable way to do that.

Comment 34

[Justin Dolske [:Dolske]]

No. Let's not over-think this.

For the vast majority of users, this UI (or something like it) is something that is utterly meaningless to users and simply shouldn't be touched. We should remove it. There are a tiny number of situations where control over TLS version usage is a valid requirement, hence the retention of this capability (via an about:config pref).

If a future situation arises where there is a security concern with TLS, we'll solve it then (by changing the default and/or adding _appropriate_ UI).

Comment 35

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to cloos from comment #33)
> Do note that there are broken but important web sites which fail unless one
> disables tls1.2 and even 1.1 in one’s browser.

The plan for these sites is to fall back to TLS 1.0 when the TLS 1.1/1.2 connection fails, in the same way we fall back to SSL 3.0 when a TLS 1.0 connection fails. (except when the site is HSTS.) Our support for TLS 1.2/1.1/1.0 is not really a defense against vulnerabilities in TLS 1.1/1.0/SSL3 unless the site is HSTS. Rather, it is, for now, going to be just a compatibility mechanism so that we continue to work for sites that start to disable older versions of TLS.

> Turning off versions will remain important forthe foreseable future.

Generally, the only people that will need to turn off versions are those that have regulatory concerns (e.g. US Government deployments) that forbid particular versions of TLS, more strictly than is really necessary. Otherwise, it is our (PSM/NSS team) to make sure the default configuration maximizes compatibility with maximum security, automatically.

> That said, about:confg is a perfectly resonable way to do that.

Really, Firefox needs to do the right thing automatically. The option will really only be for government users (though, of course, anybody can shoot themselves with them).

Comment 36

[Gervase Markham [:gerv]]

Limi is right. Kill this UI.

Gerv

Comment 37

[Alex Xu]

Can we *please* merge this along with bug 733642 (to reset prefs)?

Target milestone is still mozilla14, so we're about 8 versions behind.

Comment 38

[u466741]

Excuse me... I know, I'm just a user... but I want to see in the UI something as important as what kind of protocol version that is enable/ disable/ available in the browser.

Isn't the privacy and security the top priority in a browser (besides supporting standards)? How can you say it's a top priority  and then make it vanished into the about:config

This thing should look more like Opera, and have a list of support protocols and support ciphers... and even better in the list of support cipher we should be able to reorder so that whatever the user/ administrator thinks is best at that time (having in the mind the vulnerabilities that exist) the browser can try first the most secure. If the connection is just being recorded this will provide more security.
Also should be able to easily disable any cipher if it comes to public acknowledgement that some cipher like for example "rsa_rc4_128_md5" is completely insecure and makes no good to anyone's security... although many web sites may use it, the user may just not want to use any one of them, that is supporting just that cipher... because prefer not to be connected with such a bad cipher, that won't really protect him. Besides would be preventing automatic downgrade attacks that may occurring in present or in the future.
Looking for this in the about:config is just very difficult for most people... and reorder priority is simply impossible.

And what if users just "screw" this settings, and stops working? Why not some kind of... "Replace to defaults" button? That easy.

The idea is that someone set the defaults that thinks are good enough for most people, but may not be that good, or not good in 1 year time... and everyone as already see how much time it takes for example for mozilla firefox add TLS 1.2, when Internet Explorer and Opera already have them for some time (and anyone can enable/ disable them individually in the GUI)... and changing bad defaults seem almost impossible sometimes, even if the users want to be more secure.
And is not just governments, company's, non for profit, and others may have strict rules, for example to be safe on the net and not have their communications compromised.

Some servers have problems with TLS 1.1, and TLS 1.2... well if every single browser supports TLS 1.1 and TLS 1.2 by default, the administrators and vendors will need to fix things and not just look to the other side not doing anything... every single day people are fixing vulnerabilities and incompatibilities, that would be just one more, and a very important one! Since TLS 1.2 is so much better than any previous version by supporting a bunch of new things like better Hash, cipher suites and solving old known bugs that are still around and probably being abused all the time... just not in the news.

Comment 39

[Zoltán Halassy]

(In reply to Roy from comment #38)
> Excuse me... I know, I'm just a user... but I want to see in the UI
> something as important as what kind of protocol version that is enable/
> disable/ available in the browser.

about:config is a kind of UI.

> Isn't the privacy and security the top priority in a browser (besides
> supporting standards)? How can you say it's a top priority  and then make it
> vanished into the about:config

The user should get sensible defaults which is secure enough, but also works most of the time. Underinformed people might heard that SSLv3 and TLSv1.0 is "insecure", so they want to turn it off. With that move, the user just successfully turned off the majority of the "secure" websites.

> This thing should look more like Opera

Use Opera then.

> Looking for this in the about:config is just very difficult for most
> people... and reorder priority is simply impossible.

If it's difficult for a user to tweak something in about:config, then she shouldn't fiddle with protocol versions and cipher suites and their order at all.

> And what if users just "screw" this settings, and stops working? Why not
> some kind of... "Replace to defaults" button? That easy.

about:config already has that feature.
And no, it's not that easy. If a user managed to screw up something, HOW does she will know, it was her, who screwed up something? Like, she enabled a lot of ciphers, and the ClientHello will get bigger than 255 bytes and the broken remote server just does not respond (like https://www.nsa.gov/ ) ? She will get a simple timeout error, how does that translate to errors in ssl settings? (Imagine a scenario when she set up that months ago, totally forgot about it, then she needs to visit a broken website she never encountered in those months)

> The idea is that someone set the defaults that thinks are good enough for
> most people, but may not be that good, or not good in 1 year time... and
> everyone as already see how much time it takes for example for mozilla
> firefox add TLS 1.2, when Internet Explorer and Opera already have them for
> some time (and anyone can enable/ disable them individually in the GUI)...

TLS 1.2 is only supported in IE from Windows 7+ (around every third Internet user has Windows XP), and turned off by default. Opera, turned off by default.
What makes you stop turning it on from about:config after TLS 1.2 landed in NSS, then Firefox starts supporting it? The development team is already on it. Be a bit patient.

> and changing bad defaults seem almost impossible sometimes, even if the
> users want to be more secure.

Yeah, "sure". If you keep only TLS 1.2 on in Opera, others off: it will report invalid certificates because it tries to reach something external which is only available with TLS 1.0. That's very functional indeed.

> Some servers have problems with TLS 1.1, and TLS 1.2... well if every single
> browser supports TLS 1.1 and TLS 1.2 by default, the administrators and
> vendors will need to fix things and not just look to the other side not
> doing anything...

Most of the users see problems as boolean: It works, or it doesn't. If a server is broken, and it does not respond to TLSv1.1+ requests; and one browser only tries TLSv1.0 and it works, and the other one tries TLSv1.1 and it does not; the average user will say the second *browser* is ****, because it doesn't show the page which was working "perfectly" with the first one, so they will stop using the second one.

Comment 40

[u466741]

(In reply to Zoltán Halassy from comment #39)

> about:config is a kind of UI.

A confusing one.
 
> The user should get sensible defaults which is secure enough, but also works
> most of the time. Underinformed people might heard that SSLv3 and TLSv1.0 is
> "insecure", so they want to turn it off. With that move, the user just
> successfully turned off the majority of the "secure" websites. 

A drop down list would prevent the disabling. If for example the user chooses some that doesn't include TLS 1.0 a warning could be given. 


> Use Opera then.

I want Firefox to be better. And I don't use Opera a lot, not because of security, but because of the rendering of the web pages and the extras work much better in firefox.


> If it's difficult for a user to tweak something in about:config, then she
> shouldn't fiddle with protocol versions and cipher suites and their order at
> all.

I understand protocol and cipher suites, and I find it difficult to set them up easily in firefox... firefox should make things easier not more difficult. And the user will mess thing be it the main UI or in the about:config .. but in the main UI is more easy to spot the problem!

> about:config already has that feature.
> And no, it's not that easy. If a user managed to screw up something, HOW
> does she will know, it was her, who screwed up something? Like, she enabled
> a lot of ciphers, and the ClientHello will get bigger than 255 bytes and the
> broken remote server just does not respond (like https://www.nsa.gov/ ) ?
> She will get a simple timeout error, how does that translate to errors in
> ssl settings? (Imagine a scenario when she set up that months ago, totally
> forgot about it, then she needs to visit a broken website she never
> encountered in those months)

If their is a limit to the cipher that can be enable on firefox, just put in the main UI and don't let user set more than the ones that can be set.

> TLS 1.2 is only supported in IE from Windows 7+ (around every third Internet
> user has Windows XP), and turned off by default. Opera, turned off by
> default.
> What makes you stop turning it on from about:config after TLS 1.2 landed in
> NSS, then Firefox starts supporting it? The development team is already on
> it. Be a bit patient.

The idea is that IF and WHEN TLS 1.1 and TLS 1.2 are available for the final users, users can clearly see and choose them.
And if this are enable by default, administrators will finally fix the problems.

> Yeah, "sure". If you keep only TLS 1.2 on in Opera, others off: it will
> report invalid certificates because it tries to reach something external
> which is only available with TLS 1.0. That's very functional indeed.

If it reports invalid connection, it may say that because user disable a previous SSL/TLS protocol that page isn't available, and if the user wants to connect either change preferences in the UI (giving the direction), or to contact the administrator to upgrade is web site.

> Most of the users see problems as boolean: It works, or it doesn't. If a
> server is broken, and it does not respond to TLSv1.1+ requests; and one
> browser only tries TLSv1.0 and it works, and the other one tries TLSv1.1 and
> it does not; the average user will say the second *browser* is ****, because
> it doesn't show the page which was working "perfectly" with the first one,
> so they will stop using the second one.

The same answer that I give previously. The browser should report that that web site doesn't support the current SSL/TLS protocol that user has chosen, so the user either changes the options in UI or contact the web site owner.

It can be even better, users can be offer a option to test and verify what secure protocol(s) the web site support(s)/ need(s)... and to compare with the settings that the user haves... it would probably solve most of support request, if it's clearly offered that option, so that user sees that the Firefox can be used on that web site, if the user enables the protocol that was disable by the user, and because the test tool says what is/ are the protocol(s) that the web site support(s)/ need(s), the user will choose one that support at least one of them, or more until the web site works properly. 
And can be add something more big like "Sorry, seems that this page can be properly seen if you change settings. Learn more below." And then follow by the information and warnings.

Comment 41

[:Gavin Sharp [email: [e-mail]]]

(In reply to Roy from comment #40)
I'm sorry, but we just don't believe that offering this UI to our users has enough benefit to outweigh the (very real) costs. "Making TLS version configuration easier" is just not one of our goals. Thankfully, Firefox has a great add-on system, so regardless of what we decide here you could install a SuperCryptoPrefsExposer add-on that lets you configure Firefox as much as you want.

Comment 42

[u466741]

I do agree that UI is not terrible needed. Although I, as user, prefer to see it.

This said, I hope that the developers do implement in the about:config (at least) some way to allow prioritization of cipher suites... that is the thing I'm missing the most (besides TLS 1.2 and TLS 1.1 protocol support)... and I supposed is not possible, even if some programmer would like to do it (in those extras). So implementing some way to prioritize the ciphers would be great!

Comment 43

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/882345a7a0a9
https://hg.mozilla.org/integration/mozilla-inbound/rev/04dbe811e4a0

Comment 44

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/882345a7a0a9

Comment 46

[Andreas Eibach]

Whee, this discussion has come down a quite a long road...
OK, let me keep it short:

Roy: (comment 38)
>Isn't the privacy and security the top priority in a browser (besides supporting standards)? How can >you say it's a top priority  and then make it vanished into the about:config
I see where you're coming from, and I also understand your concern. It was basically what Kai pointed out remotely between the lines far above in comment 9:
>- a researcher/hacker discovers a flaw in SSL 3
>[...]
>Instead of having users to fiddle with about:config,
>I would rather be able to tell users "go to prefs, disable SSL 3".

So what you guys appear to fear---from a user's standpoint---is, in blunt wording, that "only experts will get the benefit of full on-line full security because they got the knowledge and/or motivation to fiddle with about:config; the rest will, say most of the time, surf the net with old insecure TLS 1.0".

Considering this from one direction, there is even some truth in there, I concede. However, if (and only if) the developers *ensure* that with a web site, the most secure TLS version is autochecked for support as first---and then falling back in case of failure---this thing will no longer be a problem to the standard user.

--

Besides, in theory, in particular for users who regularly visit the same bunch of preferred sites, there could be yet another approach:
You could configure this in a similar "white-list" fashion as you do with NoScript and XSS exceptions:
ALWAYS use TLS 1.1 (or 1.2, in future) except for a special list of sites you define yourself that definitely need ol' TLS 1.0 and may do so. The others may not - they must use TLS 1.[12].

The standard (though security-minded) user might sleep more soundly eventually, since he/she would know for sure that TLS1.0 negotiation attempts will never be taken *unless* the site is listed on the user-created "can_use_tls_10" white-list.

Comment 47

[Alex Xu]

(In reply to Andreas Eibach from comment #46)
> Whee, this discussion has come down a quite a long road...
> OK, let me keep it short:
> 
> Roy: (comment 38)
> >Isn't the privacy and security the top priority in a browser (besides supporting standards)? How can >you say it's a top priority  and then make it vanished into the about:config
> I see where you're coming from, and I also understand your concern. It was
> basically what Kai pointed out remotely between the lines far above in
> comment 9:
> >- a researcher/hacker discovers a flaw in SSL 3
> >[...]
> >Instead of having users to fiddle with about:config,
> >I would rather be able to tell users "go to prefs, disable SSL 3".
> 
> So what you guys appear to fear---from a user's standpoint---is, in blunt
> wording, that "only experts will get the benefit of full on-line full
> security because they got the knowledge and/or motivation to fiddle with
> about:config; the rest will, say most of the time, surf the net with old
> insecure TLS 1.0".
> 
> Considering this from one direction, there is even some truth in there, I
> concede. However, if (and only if) the developers *ensure* that with a web
> site, the most secure TLS version is autochecked for support as first---and
> then falling back in case of failure---this thing will no longer be a
> problem to the standard user.
> 
> --
> 
> Besides, in theory, in particular for users who regularly visit the same
> bunch of preferred sites, there could be yet another approach:
> You could configure this in a similar "white-list" fashion as you do with
> NoScript and XSS exceptions:
> ALWAYS use TLS 1.1 (or 1.2, in future) except for a special list of sites
> you define yourself that definitely need ol' TLS 1.0 and may do so. The
> others may not - they must use TLS 1.[12].
> 
> The standard (though security-minded) user might sleep more soundly
> eventually, since he/she would know for sure that TLS1.0 negotiation
> attempts will never be taken *unless* the site is listed on the user-created
> "can_use_tls_10" white-list.

This is already being implemented in bug 839310.

Comment 48

[Andreas Eibach]

Thanks Alex, haven't yet read there!

(Sometimes I could even get annoyed that always someone beats me to it in ideas. ;))